home *** CD-ROM | disk | FTP | other *** search
/ Language/OS - Multiplatform Resource Library / LANGUAGE OS.iso / clean / sun3.lha / Sun3 / Changes0.7to0.8 < prev    next >
Text File  |  1992-08-10  |  13KB  |  256 lines
  1.  
  2. 7     Changes and Additions
  3.  
  4. Compared with the  previous release of  the Concurrent  Clean System  (version 
  5. 0.7) the  language  Concurrent Clean  has changed  considerably, especially by
  6. introducing guards for the specification of conditional  expressions. Further-
  7. more some more or less cosmetic syntax improvements have been carried through.
  8.  
  9. Apart from the changes made to the language also some very important additions
  10. have  been  implemented. The most important addition  is  the  I/O  interface.
  11. Libraries  have  been implemented that contain functions that make  the  high-
  12. level  specification of modern I/O possible in Concurrent  Clean.  Furthermore
  13. the  concept  of  macro's has been added and a type attribute  that  makes  it
  14. possible to check single-threadedness of objects at compile-time.
  15.  
  16. In the following sections these changes and additions will be treated briefly.
  17.  
  18. 7.1   Changes
  19.  
  20. Guarded expressions
  21.  
  22. In Concurrent Clean version 0.7 one had to use the predefined IF rule to write
  23. down  conditional expressions. Unfortunately the use of the IF rule  does  not
  24. contribute  to the readability of a program, especially when a  lot  of  cases
  25. have to be distinguished.
  26.  
  27. In   Concurrent  Clean  version  0.8  therefore  conditional  expressions  are
  28. specified  by means of guards (see section 2.2). For compatibility with  older
  29. versions  of  Concurrent Clean the IF function has been built-in, which  means
  30. that  it has been removed from the deltaM library and has become part  of  the
  31. language.   This built-in IF function should not be used any more because  the
  32. use  of  guards generally leads to more elegant and (sometimes) more efficient
  33. programs and moreover because applications of the IF function sometimes cannot
  34. be parsed correctly on places where the keywoard 'IF' is also valid.
  35.    
  36.    Example  of  the use of guards instead of the IF rule. In Concurrent  Clean
  37.    version  0.7 the third alternative of the Merge function (merge two  sorted
  38.    lists of integers, remove doubles) looks as follows:
  39.      
  40.          Merge f:[a|b] g:[c|d]     ->    IF (< a c)
  41.                                             [a | Merge b g]
  42.                                             (IF (= a c)
  43.                                                 (Merge f d)
  44.                                                 [c | Merge f d]
  45.                                             );
  46.      
  47.    A  much  more elegant way of defining this function alternative  exists  in
  48.    Concurrent Clean version 0.8:
  49.      
  50.          Merge f:[a|b] g:[c|d]     ->    [a | Merge b g], IF < a c
  51.                                    ->    Merge f d      , IF = a c
  52.                                    ->    [c | Merge f d];
  53.  
  54. An  important difference between guards and the IF rule is that the IF rule is
  55. a  function  whereas  the  concept of guards is a syntactical  construct.  For
  56. example,  when a guarded expression is annotated with {P} or {I}  the  process
  57. will only be created when the guard evaluates to True. On the other hand, when
  58. then  or else part of the IF rule have a process annotation a process will  be
  59. started  up  immediately, because process annotations force the evaluation  of
  60. the  annotated argument to root normal form. This process will possibly become
  61. a  garbage  process,  of which the root normal form will  be  removed  by  the
  62. garbage collector.
  63.    
  64.    As  an  example  the definition of the Filter function  for  the  Sieve  of
  65.    Eratosthenes  is  given in old and new syntax. In the old syntax  an  extra
  66.    function Filter' is necessary to prevent the creation of garbage processes:
  67.    
  68.      ::  Filter INT [INT]     -> [INT];
  69.          Filter pr [n|str]    -> IF (=I (MOD n pr) 0)
  70.                                     (Filter pr str)
  71.                                     (Filter' pr str);
  72.      
  73.      ::  Filter' INT [INT]    -> [INT];
  74.          Filter' pr str  -> [pr | {I} Filter pr str];
  75.      
  76.    When using guards in Concurrent Clean version 0.8 there is no need to worry
  77.    about possible garbage processes:
  78.      
  79.      ::  Filter INT [INT]     -> [INT];
  80.          Filter pr [n|str]    -> Filter pr str , IF = (% n pr) 0
  81.                               -> [pr | {I} Filter pr str];
  82.  
  83. Cosmetic syntax changes
  84.  
  85. Compared to Concurrent Clean 0.7 some syntax changes have been carried through
  86. that  make  Concurrent  Clean  version 0.8 more uniform,  straightforward  and
  87. readable than its predecessor.
  88.  
  89. Predefined functions working on integers
  90.  
  91. In  version 0.7 of the Concurrent Clean System almost all predefined functions
  92. working  on  integers  ended  with  the letter  I  to  distinguish  them  from
  93. predefined functions for other basic types such as REAL and CHAR. Because  the
  94. predefined  functions for integers are the most frequently used  it  has  been
  95. decided  to  drop  the  I  extension  for  these  functions  in  version  0.8.
  96. Furthermore the predefined function 'MOD' has been changed in to  '%'.  For  a
  97. complete overview of all delta rules the reader is referred to appendix B.
  98.  
  99. Rule alternatives
  100.  
  101. In  Concurrent Clean 0.8 rule alternatives are separated by a semicolon  (';')
  102. instead of a vertical bar ('|').
  103.    
  104.    As  an  example  of the syntax changes the Fac function  is  given  in  old
  105.    syntax:
  106.    
  107.      Fac 0 -> 1                 |
  108.      Fac n -> *I n (Fac (--I n));
  109.      
  110.    And in new syntax:
  111.    
  112.      Fac 0 -> 1;
  113.      Fac n -> * n (Fac (-- n));
  114.  
  115. Algebraic type definitions
  116.  
  117. In  Concurrent  Clean  version 0.7 the left-hand-side  of  an  algebraic  type
  118. definition had to be repeated in every alternative of the type:algebraic type.
  119. Alternatives  of algebraic types were separated by a vertical  bar  ('|').  In
  120. version  0.8  the left-hand-side of an algebraic type definition needs  to  be
  121. specified  only  once and the alternatives are separated by  either  an  arrow
  122. symbol ('->') or a vertical bar ('|').
  123.    
  124.    As examples of the use of the new syntax for algebraic types the types List
  125.    and Bool are given in old and new syntax. In version 0.7 syntax:
  126.    
  127.      ::  List x     -> Nil               |
  128.          List x     -> Cons x (List x)   ;
  129.      
  130.      ::  Bool       -> True   |
  131.          Bool       -> False  ;
  132.      
  133.    In the new syntax this becomes:
  134.    
  135.      ::  List x     -> Nil
  136.                     -> Cons x (List x);
  137.      
  138.      ::  Bool       -> True | False;
  139.  
  140. From the examples it should be clear how the two separators ('|' and '->') are
  141. meant to be used.
  142.  
  143. List denotations
  144.  
  145. In  Concurrent Clean version 0.8 it is now possible to prefix a list with more
  146. than   one  element.  This  means  one  can  write  [a,b,c|rest]  instead   of
  147. [a|[b|[c|rest]]].
  148.  
  149. Comments
  150.  
  151. In  Concurrent  Clean 0.7 comments had to be preceded with two  vertical  bars
  152. ('||').  When  two vertical bars were encountered the rest of  that  line  was
  153. considered  to  be  comment. In version 0.8 there are two ways  of  specifying
  154. comments. Firstly by preceding it by two equals symbols ('=='), which has  the
  155. same  meaning as the vertical bars of version 0.7. Secondly it is now possible
  156. to  specify  comments by means of comment brackets ('<<' and  '>>')  that  can
  157. enclose  any  number  of  characters and lines in a  Clean  program.  Comments
  158. enclosed  in comment brackets can also be nested. When comment brackets  occur
  159. in  a string denotation inside bracketed comment this will be parsed correctly
  160. when the string denotation is correct.
  161.  
  162. 7.2   Additions
  163.  
  164. Macro's
  165.  
  166. One  of  the  new features of Concurrent Clean version 0.8 is the  concept  of
  167. macro's.  Besides TYPE blocks and RULE blocks now also MACRO blocks may  occur
  168. in  a  Clean module. At compile time the right-hand-side of a macro definition
  169. will  be  substituted for every occurrence of the left-hand-side of the  macro
  170. definition.  Macro's may have parameters but it is not allowed  to  specify  a
  171. pattern  on  the  left-hand-side of a macro definition. A  macro  rule  always
  172. consists  of  a  single  alternative. It is clear that, at  compile-time,  the
  173. rewriting  of  the  macros  should always terminate.  This  is  guaranteed  by
  174. prohibiting macros that are recursive or mutually dependent.
  175.  
  176. The  main  reason  for implementing macro's is that function definitions  that
  177. assign a name to a constant cannot be used as a pattern on the left-hand-side.
  178. Macro's  on the other hand can be used as patterns. Furthermore the use  of  a
  179. macro's  instead of non-recursive functions will speed up a Clean  program  be
  180. cause  less function calls need to be done. A disadvantage is that  more  code
  181. will  be  generated  when (parameterized) macro's are  used  instead  of  non-
  182. recursive functions. Some examples of macro's in Concurrent Clean:
  183.    
  184.      MACRO
  185.          Size                 -> 6;
  186.          UnsortedList         -> [3,1,5,2,4];
  187.          Singleton x          -> [x];
  188.          Pair a b             -> (a,b);
  189.          +SC string char -> +S string (CTOS char);
  190.          *R4 r1 r2 r3 r4 -> *R r1 (*R r2 (*R r3 r4)));
  191.  
  192. A  complete description of the concept of macro's in Concurrent Clean  can  be
  193. found in section 2.4 of this manual.
  194.  
  195. Unique types
  196.  
  197. Nodes of a graph to which there exists at most one path starting from the root
  198. of  that graph are called single-threaded or unique. When implementing the I/O
  199. interface for Concurrent Clean the need was felt to have a way to check single-
  200. threadedness or uniqueness of objects at compile-time. In this way  a  lot  of
  201. run-time checks can be omitted, which enhances the efficiency of advanced  I/O
  202. in  Concurrent  Clean. Moreover, for, for example, a future implementation  of
  203. arrays in Concurrent Clean a compile-time check on uniqueness can also be very
  204. useful.
  205.  
  206. Unfortunately,  at  compile  time  type:unique  typeness  is  an   undecidable
  207. property.  In Concurrent Clean version 0.8 therefore a decidable approximation
  208. of  uniqueness has been incorporated. For this purpose, types can be  supplied
  209. with  UNQ  (pronounce as 'unique') attributes. Intuitively, this UNQ attribute
  210. enforces that the corresponding actual nodes of the graph will be unique.  The
  211. compiler  will  check whether nodes that are UNQ attributed  are  indeed  used
  212. uniquely.  Section 3.6 contains a complete overview of the use and  the  seman
  213. tics of the UNQ type attribute.
  214.  
  215. Modern input / output
  216.  
  217. For  Concurrent  Clean  version 0.8 a sophisticated  I/O  interface  has  been
  218. written.  The  I/O interface is written entirely in Concurrent  Clean  and  is
  219. machine independent. Underneath the I/O Interface only a thin layer of machine
  220. dependent  routines has been implemented that forms the interface between  the
  221. Macintosh toolbox and Concurrent Clean. Interfaces with other window  oriented
  222. operating  systems such as XWindows/Open Look are under development.  The  I/O
  223. interface contains functions to define menu's and dialogues, to draw  pictures
  224. and strings, to handle windows and mice etcetera.
  225.  
  226. Also new I/O:file I/O operations have been implemented (see appendix B, module
  227. deltaFile),  which  means  that the file I/O operations  of  Concurrent  Clean
  228. version  0.7  have been dropped. Because the version 0.8 file  I/O  operations
  229. only work when concrete code is generated, the version 0.7 file I/O operations
  230. are  still  supported to be able to do file I/O in the simulator / interpreter
  231. (see  appendix  B, module deltaIO). In future versions of the  language  these
  232. operations  will  not be supported anymore: the new file I/O  operations  will
  233. then also be available for the simulator / interpreter.
  234.  
  235. The  elegance of the specification of modern I/O in Concurrent Clean has  been
  236. achieved by using a new approach to functional I/O. This approach is based  on
  237. an  explicit  environment passing scheme, in which the environment  is  passed
  238. only to functions that have a side-effect. Unique types have been used to guar
  239. antee single threaded use of the environment. This new approach for functional
  240. I/O is called Concurrent Clean event I/O.
  241.  
  242. A  detailed  overview of functional I/O in Concurrent Clean  is  presented  in
  243. chapter 5.
  244. _______________________________
  245. * Warning: The Concurrent Clean System version 0.8 only supports the new I/O
  246. facilities when concrete code is generated. In the interpreter/simulator the
  247. (very limited) I/O features of version 0.7 can still be used to write
  248. "interactive" programs.
  249. * Unique in the sense that there is no other item with the same id. This has
  250. nothing to do with the UNQ type attribute.
  251. * Warning: The Concurrent Clean System version 0.8 only supports parallelism
  252. when the interpreter /simulator is used. Parallel code can already be
  253. generated for a Parsytec Supercluster. For Macintosh and Sun a generator for
  254. parallel code is under development. At the moment parallel annotations are
  255. ignored when concrete code is generated.
  256.